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MPLS Upstream Label Assignment for LDP 
Abstract 


This document describes procedures for distributing upstream-assigned 
labels for the Label Distribution Protocol (LDP). It also describes 

how these procedures can be used for avoiding branch Label Switching 

Router (LSR) traffic replication on a LAN for LDP point-to-multipoint 
(P2MP) Label Switched Paths (LSPs). 
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1. Introduction 


This document describes procedures for distributing upstream-assigned 
labels [RFC5331] for Label Distribution Protocol (LDP) [RFC5036]. 
These procedures follow the architecture for MPLS upstream label 
assignment described in [RFC5331]. 


This document describes extensions to LDP that a Label Switching 
Router (LSR) can use to advertise whether the LSR supports upstream 
label assignment to its neighboring LSRs. 


This document also describes extensions to LDP to distribute 
upstream-assigned labels. 


The usage of MPLS upstream label assignment using LDP to avoid branch 
LSR traffic replication on a LAN for LDP point-to-multipoint (P2MP) 
Label Switched Paths (LSPs) [RFC6388] is also described. 


2. Specification of Requirements 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


3. LDP Upstream Label Assignment Capability 


According to [RFC5331], upstream-assigned label bindings MUST NOT be 
used unless it is known that a downstream LSR supports them. This 
implies that there MUST be a mechanism to enable an LSR to advertise 
to its LDP neighbor LSR(s) its support of upstream-assigned labels. 


A new Capability Parameter, the LDP Upstream Label Assignment 
Capability, is introduced to allow an LDP peer to exchange with its 
peers, its support of upstream label assignment. This parameter 
follows the format and procedures for exchanging Capability 
Parameters defined in [RFC5561]. 


Following is the format of the LDP Upstream Label Assignment 
Capability Parameter: 


0 1 2 3 
OnE 23 e E FB Oe OOD UO 3 AS, 6. P98 Os. O8 Des 2234 25) 6.0 FB: 9-00 AL 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++++ 

|1|0| Upstrm Lbl Ass Cap (0x0507) | Length (= 1) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++++ 
|1| Reserved | 

+-+-+-+-+-+-+-+-+ 
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If an LSR includes the Upstream Label Assignment Capability in LDP 
Initialization messages, it implies that the LSR is capable of both 
distributing upstream-assigned label bindings and receiving upstream- 
assigned label bindings. The reserved bits MUST be set to zero on 
transmission and ignored on receipt. The Upstream Label Assignment 
Capability Parameter MUST be carried only in LDP Initialization 
messages and MUST be ignored if received in LDP Capability messages. 


4. Distributing Upstream-Assigned Labels in LDP 


An optional LDP TLV, Upstream-Assigned Label Request TLV, is 
introduced. To request an upstream-assigned label, an LDP peer MUST 
include this TLV in a Label Request message. 


0 1 2 3 
012345678901234567890123456789 021 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++++ 


|o|o|Upstrm-Ass Lbl Req (0x0205) | Length 
+-+-+-+-+-+-+-+-+-+-+-+ ++ 
| Reserved | 


+-4-4-4-4-4-4-4-4-4-4+-4+-4-4-4-4-4+-4+-4+-4-4-4+-4-4+-4+-4-4-4+-4-4-4-4-4 


An optional LDP TLV, Upstream-Assigned Label TLV, is introduced to 
signal an upstream-assigned label. Upstream-Assigned Label TLVs are 
carried by the messages used to advertise, release, and withdraw 
upstream-assigned label mappings. 


0 1 2 3 
OSE 2 35. On A 38> 19! OS ah. 2. SAS OF AE (Oe dy 22 3) 4s 25: On 7. 889? Ofc 
+-+-+-+-+-+-+-+-+-+-+-+ ++ 

|oļo| Upstrm-Ass Label (0x0204) | Length 

+-+-+-+-+-+-+-+-+-+-+- ++ 
| Reserved | 
+-+-+-+-+-+-+-+-+-+-+- ++ 
| Label | 
+-+-+-+-+-+-+-+-+-+-+-+- ++ 


The Label field is a 20-bit label value as specified in [RFC3032], 
represented as a 20-bit number in a 4-octet field as specified in 
Section 3.4.2.1 of RFC 5036 [RFC5036]. 

4.1. Procedures 
Procedures for Label Mapping, Label Request, Label Abort, Label 


Withdraw, and Label Release follow [RFC5036] other than the 
modifications pointed out in this section. 
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An LDP LSR MUST NOT distribute the Upstream-Assigned Label TLV to a 
neighboring LSR if the neighboring LSR has not previously advertised 
the Upstream Label Assignment Capability in its LDP Initialization 
messages. An LDP LSR MUST NOT send the Upstream-Assigned Label 
Request TLV to a neighboring LSR if the neighboring LSR has not 
previously advertised the Upstream Label Assignment Capability in its 
LDP Initialization messages. 


As described in [RFC5331], the distribution of upstream-assigned 
labels is similar to either ordered LSP control or independent LSP 
control of the downstream-assigned labels. 


When the label distributed in a Label Mapping message is an upstream- 
assigned label, the Upstream-Assigned Label TLV MUST be included in 
the Label Mapping message. When an LSR receives a Label Mapping 
message with an Upstream-Assigned Label TLV and it does not recognize 
the TLV, it MUST generate a Notification message with a status code 
of "Unknown TLV" [RFC5036]. If it does recognize the TLV but is 
unable to process the upstream label, it MUST generate a Notification 
message with a status code of "No Label Resources". If the Label 
Mapping message was generated in response to a Label Request message, 
the Label Request message MUST contain an Upstream-Assigned Label 
Request TLV. An LSR that generates an upstream-assigned label 
request to a neighbor LSR, for a given FEC, MUST NOT send a 
downstream label mapping to the neighbor LSR for that FEC unless it 
withdraws the upstream-assigned label binding. Similarly, if an LSR 
generates a downstream-assigned label request to a neighbor LSR, for 
a given FEC, it MUST NOT send an upstream label mapping to that LSR 
for that FEC, unless it aborts the downstream-assigned label request. 


The Upstream-Assigned Label TLV may be optionally included in Label 
Withdraw and Label Release messages that withdraw/release a 
particular upstream-assigned label binding. 


5. LDP Tunnel Identifier Exchange 


As described in [RFC5331], a specific upstream LSR (Ru) MAY transmit 
an MPLS packet, the top label of which (L) is upstream assigned, to 
its downstream neighbor LSR (Rd). In this case, the fact that L is 
upstream assigned is determined by Rd by the tunnel on which the 
packet is received. There must be a mechanism for Ru to inform Rd 
that a particular tunnel from Ru to Rd will be used by Ru for 
transmitting MPLS packets with upstream-assigned MPLS labels. 


When LDP is used for upstream label assignment, the Interface ID TLV 
[RFC3472] is used for signaling the Tunnel Identifier. If Ru uses an 
IP or MPLS tunnel to transmit MPLS packets with upstream assigned 
labels to Rd, Ru MUST include the Interface ID TLV in the Label 
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Mapping messages along with the Upstream-Assigned Label TLV. The 
IPv4/IPv6 Next/Previous Hop Address and the Logical Interface ID 
fields in the Interface ID TLV SHOULD be set to 0 by the sender and 
ignored by the receiver. The Length field indicates the total length 


of the TLV, i. 


e., 


4 + the length of the Value field in octets. A 
Value field whose length is not a multiple of four MUST be zero- 
padded so that the TLV is four-octet aligned. 


Hence the IPv4 Interface ID TLV has the following format: 


0 


1 2 3 


01234567890123456789012345678901 
Stata tartar ta tar ta tate tata tata ta tata ta tata ta HHHMH 
(0x082d) | Length | 


+-+ 
oļol 
+-+ 


+ 
| 
+ 
| 
+-+-+ 
| 
+-+-+ 
| 
+-+-+ 
The IPv6 


0 


T 
+-+-+ 


+-+-+ 


+-+-+ 


+-+-+ 


ype 
—-+-— 


—-+—-— 


=+- 


+- 


+ 


+ 


+ 


+ 


Interface 


+ 


+ 


+ 


+ 


T 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +++ 
IPv4 Next/Previous Hop Address (0) | 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +++ 
Logical Interface ID (0) | 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +++ 
Sub-TLVs | 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +++ 


D TLV has the following format: 


1 2 3 


01234567890123456789012345678901 
+-+-+-+-+-+-+-+-+-+-+-+-+-++HHH HHHH 
(0x082e) | Length | 


O 
+— + 
O 
+—+ 


+ 
| 
+ 
| 
+-+-+ 
| 
+-+-+ 
| 
+-+-+ 


As shown 
Four new 


Tunnels, 


T 
+-+-+ 


+-+-+ 


+-+-+ 


+-+-+ 


ype 
+- 


=+- 


—-+-— 


—-+—-— 


+ 


+ 


+ 


+ 


+ 


+ 


+ 


+ 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
IPv6 Next/Previous Hop Address (0) | 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Logical Interface ID (0) | 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Sub-TLVs | 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


in the above figures, the Interface ID TLV carries sub-TLVs. 
Interface ID sub-TLVs are introduced to support RSVP - 
Traffic Engineering 
and context labels. The sub-TLV value in the sub-TLV acts 
as the tunnel identifier. 
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The following sub-TLVs are introduced: 
1. RSVP-TE P2MP LSP TLV (Type = 28) 


The value of the TLV is the RSVP-TE P2MP LSP SESSION Object 
[RFC4875]. 


Below is the RSVP-TE P2MP LSP TLV format when carried in the IPv4 
Interface ID TLV: 


0 1 2 3 
OT 22 34 OP Oe PB 9 OT 2 3349.6 EB Ga Or D2 3: AO. TB: 9.*-0) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Type (0Ox1c) | 16 | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| P2MP ID | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| MUST be zero | Tunnel ID | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Extended Tunnel ID | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ 


Below is the RSVP-TE P2MP LSP TLV format when carried in the IPv6 
Interface ID TLV: 


0 1 2 3 

Or 22 304 Os PB Oo OT 234: D6 FB OO" L BS Ae 9 6. TB OO T 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Type (Oxic) | 28 | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| P2MP ID | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++ 
| MUST be zero | Tunnel ID | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Extended Tunnel ID | 
| | 
I gk eee wep ee site ts *y T | 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


This TLV identifies the RSVP-TE P2MP LSP. It allows Ru to tunnel an 
"inner" LDP P2MP LSP, the label for which is upstream assigned, over 
an "outer" RSVP-TE P2MP LSP that has leaves <Rd1...Rdn>. The RSVP-TE 
P2MP LSP IF_ID TLV allows Ru to signal to <Rd1...Rdn> the binding of 
the inner LDP P2MP LSP to the outer RSVP-TE P2MP LSP. The control- 
plane signaling between Ru and <Rd1...Rdn> for the inner P2MP LSP 
uses targeted LDP signaling messages. 
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2. LDP P2MP LSP TLV (Type = 29) 


The value of the TLV is the LDP P2MP FEC as defined in [RFC6388] and 
has to be set as per the procedures in [RFC6388]. Here is the format 
of the LDP P2MP FEC as defined in [RFC6388]: 


0 1 2 3 
0. 23490 6 7-89 O12 8 AO BO) D2 BA D6. FB e 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|P2MP Type | Address Family | Address Length| 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
` Root Node Address i 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Opaque Length | Opaque Value ... 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 


| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


The Address Family MUST be set to IPv4, the Address Length MUST be 
set to 4, and the Root Node Address MUST be set to an IPv4 address 
when the LDP P2MP LSP TLV is carried in the IPv4 Interface ID TLV. 
The Address Family MUST be set to IPv6, the Address Length MUST be 
set to 16, and the Root Node Address MUST be set to an IPv6 address 
when the LDP P2MP LSP TLV is carried in the IPv6 Interface ID TLV. 


The TLV value identifies the LDP P2MP LSP. It allows Ru to tunnel an 
inner LDP P2MP LSP, the label for which is upstream assigned, over an 
outer LDP P2MP LSP that has leaves <Rd1...Rdn>. The LDP P2MP LSP 
IF_ID TLV allows Ru to signal to <Rd1...Rdn> the binding of the inner 
LDP P2MP LSP to the outer LDP-P2MP LSP. The control-plane signaling 
between Ru and <Rdl...Rdn> for the inner P2MP LSP uses targeted LDP 
signaling messages. 


3. IP Multicast Tunnel TLV (Type = 30) 


In this case, the TLV value is a <Source Address, Multicast Group 
Address> tuple. Source Address is the IP address of the root of the 
tunnel (i.e., Ru), and Multicast Group Address is the Multicast Group 
Address used by the tunnel. The addresses MUST be IPv4 addresses 
when the IP Multicast Tunnel TLV is included in the IPv4 Interface ID 
TLV. The addresses MUST be IPv6 addresses when the IP Multicast 
Tunnel TLV is included in the IPv6 Interface ID TLV. 
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4. MPLS Context Label TLV (Type = 31) 


In this case, the TLV value is a <Source Address, MPLS Context Label> 
tuple. The Source Address belongs to Ru and the MPLS Context Label 
is an upstream-assigned label, assigned by Ru. The Source Address 
MUST be set to an IPv4 address when the MPLS Context Label TLV is 
carried in the IPv4 Interface ID TLV. The Source Address MUST be set 
to an IPv6 address when the MPLS Context Label TLV is carried in the 
IPv6 Interface ID TLV. This allows Ru to tunnel an inner LDP P2MP 
LSP, the label of which is upstream assigned, over an outer one-hop 
MPLS LSP, where the outer one-hop LSP has the following property: 


O The label pushed by Ru for the outer MPLS LSP is an upstream- 
assigned context label, assigned by Ru. When <Rdl...Rdn> 
perform an MPLS label lookup on this label, a combination of 
this label and the incoming interface MUST be sufficient for 
<Rd1l...Rdn> to uniquely determine Ru’s context-specific label 
space to look up the next label on the stack. <Rdl...Rdn> MUST 
receive the data sent by Ru with the context-specific label 
assigned by Ru being the top label on the label stack. 


Currently, the usage of the Context Label TLV is limited only to LDP 
P2MP LSPs on a LAN as specified in the next section. The Context 
Label TLV MUST NOT be used for any other purpose. 


Note that when the outer P2MP LSP is signaled with RSVP-TE or MLDP, 
the above procedures assume that Ru has a priori knowledge of all the 
<Rdl, ... Rdn>. In the scenario where the outer P2MP LSP is signaled 
using RSVP-TE, Ru can obtain this information from RSVP-TE. However, 
in the scenario where the outer P2MP LSP is signaled using MLDP, MLDP 
does not provide this information to Ru. In this scenario, the 
procedures by which Ru could acquire this information are outside the 
scope of this document. 


6. LDP Point-to-Multipoint LSPs on a LAN 


This section describes one application of upstream label assignment 
using LDP. Further applications are to be described in separate 
documents. 


[RFC6388] describes how to setup P2MP LSPs using LDP. On a LAN the 
solution relies on "ingress replication". An LSR on a LAN, that is a 
branch LSR for a P2MP LSP (say Ru), sends a separate copy of a packet 
that it receives on the P2MP LSP to each of the downstream LSRs on 
the LAN (say <Rdl...Rdn>) that are adjacent to it in the P2MP LSP. 


It is desirable for Ru to send a single copy of the packet for the 
LDP P2MP LSP on the LAN, when there are multiple downstream routers 
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on the LAN that are adjacent to Ru in that LDP P2MP LSP. This 
requires that each of <Rdl...Rdn> must be able to associate the label 
L, used by Ru to transmit packets for the P2MP LSP on the LAN, with 
that P2MP LSP. It is possible to achieve this using LDP upstream- 
assigned labels with the following procedures. 


Consider an LSR Rd that receives the LDP P2MP FEC [RFC6388] from its 
downstream LDP peer. Additionally, consider that the upstream 
interface to reach LSR Ru that is the next hop to the P2MP LSP root 
address (Pr) in the LDP P2MP FEC is a LAN interface (Li) and that Rd 
and Ru support upstream-assigned labels. In this case, instead of 
sending a Label Mapping message as described in [RFC6388], Rd sends a 
Label Request message to Ru. This Label Request message MUST contain 
an Upstream-Assigned Label Request TLV. 


On receiving this message, Ru sends back a Label Mapping message to 
Rd with an upstream-assigned label. This message also contains an 
Interface ID TLV with an MPLS Context Label sub-TLV, as described in 
the previous section, with the value of the MPLS label set to a value 


assigned by Ru on interface Li as specified in [RFC5331]. Processing 
of the Label Request and Label Mapping messages for LDP upstream- 
assigned labels is as described in Section 4.1. If Ru receives a 


Label Request for an upstream-assigned label for the same P2MP FEC 
from multiple downstream LSRs on the LAN, <Rdl...Rdn>, it MUST send 
the same upstream-assigned label to each of <Rdl...Rdn>. 


Ru transmits the MPLS packet using the procedures defined in 


[RFC5331] and [RFC5332]. The MPLS packet transmitted by Ru contains 
as the top label the context label assigned by Ru on the LAN 
interface, Li. The bottom label is the upstream label assigned by Ru 


to the LDP P2MP LSP. The top label is looked up in the context of 

the LAN interface (Li) by a downstream LSR on the LAN. This lookup 
enables the downstream LSR to determine the context-specific label 

space in which to look up the inner label. 


Note that <Rdl...Rdn> may have more than one equal-cost next hop on 
the LAN to reach Pr. It MAY be desirable for all of them to send the 
label request to the same upstream LSR and they MAY select one 
upstream LSR using the following procedure: 


1. The candidate upstream LSRs are numbered from lower to higher IP 
address. 


2. The following hash is performed: H = (Sum Opaque value) modulo N, 
where N is the number of candidate upstream LSRs. The Opaque 
value is defined in [RFC6388] and comprises the P2MP LSP 
identifier. 
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3. The selected upstream LSR U is the LSR that has the number H. 


This allows for load balancing of a set of LSPs among a set of 
candidate upstream LSRs, while ensuring that on a LAN interface, a 
single upstream LSR is selected. It is also to be noted that the 
procedures in this section can still be used by Rd and Ru if other 
LSRs on the LAN do not support upstream label assignment. Ingress 
replication and downstream label assignment will continue to be used 
for LSRs that do not support upstream label assignment. 


7. IANA Considerations 

7.1. LDP TLVs 
IANA maintains a registry of LDP TLVs at the registry "Label 
Distribution Protocol" in the sub-registry called "TLV Type Name 


Space". 


This document defines a new LDP Upstream Label Assignment Capability 
TLV (Section 3). IANA has assigned the value 0x0507 to this TLV. 


This document defines a new LDP Upstream-Assigned Label TLV (Section 
4). IANA has assigned the type value of 0x204 to this TLV. 


This document defines a new LDP Upstream-Assigned Label Request TLV 
(Section 4). IANA has assigned the type value of 0x205 to this TLV. 


7.2. Interface Type Identifiers 


[RFC3472] defines the LDP Interface ID IPv4 and IPv6 TLV. These top- 
level TLVs can carry sub-TLVs dependent on the interface type. These 
sub-TLVs are assigned "Interface ID Types". IANA maintains a 
registry of Interface ID Types for use in GMPLS in the registry 
"Generalized Multi-Protocol Label Switching (GMPLS) Signaling 
Parameters" and sub-registry "Interface_ID Types". IANA has made the 
corresponding allocations from this registry as follows: 


RSVP-TE P2MP LSP TLV (value 28) 
- LDP P2MP LSP TLV (value 29) 
- IP Multicast Tunnel TLV (value 30) 


— MPLS Context Label TLV (value 31) 
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8. Security Considerations 


The security considerations discussed in [RFC5036], [RFC5331], and 
[RFC5332] apply to this document. 


More detailed discussion of security issues that are relevant in the 
context of MPLS and GMPLS, including security threats, related 
defensive techniques, and the mechanisms for detection and reporting, 
are discussed in "Security Framework for MPLS and GMPLS Networks" 
[RFC5920]. 
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